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Abstract.  In  this  paper  we  discuss  how  we  intend  to  develop  a  special¬ 
ized  theorem  proving  environment  for  the  Hybrid  I/O  Automata  (HIOA) 
framework  [7]  over  the  PVS  [11]  theorem  prover,  and  some  of  the  issues 
involved.  In  particular,  we  describe  approaches  to  using  PVS  that  allow 
and  encourage  the  development  of  useful  proof  strategies,  and  note  some 
desired  PVS  features  that  would  further  help  us  to  do  so  for  our  HIOA 
environment. 


1  Introduction 

Interest  in  specialized  theorem  proving  environments  has  emerged  from  various 
application  domains  [3,4,  6, 1].  A  major  motivation  for  developing  such  environ¬ 
ments  is  to  relieve  the  developers  and  verification  engineers  from  mastering  the 
specification  language  and  the  proof  commands  of  a  general  theorem  prover. 
Specialized  environments  also  help  expert  users  of  theorem  provers  by  replacing 
repetitive  proof  patterns  with  strategies,  and  by  making  it  possible  to  generate 
human  readable  proofs. 

We  plan  to  develop  a  specialized  theorem  proving  environment  to  be  used 
with  the  Hybrid  I/O  Automata  (HIOA)  framework.  HIOA  is  a  very  general 
framework  for  modeling  systems  with  both  discrete  and  continuous  behavior, 
and  subsumes  both  the  timed  and  untimed  I/O  automata  models.  Therefore, 
any  strategies  and  metatheories  for  HIOA  would  be  applicable  to  timed  and  un¬ 
timed  I/O  automata  as  well.  A  theory  template  for  specifying  HIOAs  has  been 
presented  in  [9].  This  formalization  of  HIOA  in  PVS  is  similar  to  the  formaliza¬ 
tion  of  Lynch- Vaandrager  (LV)  timed  automaton  [8]  in  the  Timed  Automaton 
Modeling  Environment  (TAME)  [1].  However,  important  differences  arise  in  the 
two  formalizations  because  LV-timed  automata  communicate  via  shared  actions 
alone,  whereas  HIOAs  also  communicate  via  shared  variables.  Therefore,  the  evo¬ 
lution  of  continuous  variables  is  modeled  in  TAME  using  time  passage  actions  to 
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capture  cumulative  changes  over  an  interval,  while  in  the  HIOA  model,  the  evo¬ 
lution  of  the  continuous  state  variables  over  time  is  modeled  using  trajectories. 
Our  HIOA  environment  must  allow  for  these  differences. 

The  rest  of  this  paper  is  organized  as  follows:  In  Section  2  we  discuss  the 
main  types  of  proofs  which  will  be  supported  by  our  HIOA  environment  and  the 
design  issues  involved  in  developing  proof  strategies  for  each  type.  In  Section  3 
we  suggest  certain  new  features  of  PVS  which  would  aid  the  development  of 
strategies  for  PVS.  Finally,  we  summarize  and  conclude  in  Section  4. 

2  Supported  Proof  Types 

Apart  from  simplifying  direct  proofs  of  properties,  the  HIOA  proving  environ¬ 
ment  will  provide  special  strategies  for  mechanizing  inductive  invariant  proofs 
and  abstraction  (e.g.,  simulation)  proofs  for  timed,  hybrid  and  untimed  I/O 
automata.  Apart  from  TAME,  another  theorem  proving  environment  has  been 
developed,  based  on  Isabelle,  which  mechanizes  invariant  proofs  for  I/O  au¬ 
tomata  [10].  In  [2],  the  authors  present  a  simulation  proof  of  a  leader  election 
protocol  in  PVS.  However,  we  have  not  come  across  any  work  which  addresses 
the  development  of  strategies  for  mechanizing  simulation  proofs. 


2.1  Inductive  Proofs 

The  approach  we  intend  to  take  for  supporting  inductive  invariant  proofs  is 
derived  from  the  Timed  Automaton  Modeling  Environment  (TAME)  [1],  As 
in  TAME,  we  will  develop  a  parameterized  theory  machine  which  defines  the 
reachable  states  of  an  automaton  in  terms  of  its  states,  initial  states,  actions 
and  (in  case  of  hybrid  I/O  automata)  activities  [9].  This  theory  will  also  estab¬ 
lish  the  theorem  that  allows  proving  invariants  inductively.  We  will  also  develop 
a  general  theory  template  which  can  be  instantiated  with  particular  state  vari¬ 
ables  and  actions  (optionally,  activities)  to  obtain  an  automatonN ame- decls 
theory  describing  the  automaton.  The  automatonN ame- decls  theory  will  im¬ 
port  an  instance  of  the  theory  machine  with  the  declared  states  and  actions 
as  parameters.  Instantiation  of  the  theory  machine  defines  reachability  and  the 
induction  theorem  for  the  particular  automaton.  All  the  Invariants  and  the  asso¬ 
ciated  lemmas  of  an  automaton  will  be  collected  and  proved  in  a  theory  named 
automatonName-  inv. 

The  advantages  of  this  (TAME)  approach  are  as  follows:  (1)  It  is  possible  to 
write  generic  strategies  which  work  for  all  automata  specified  using  the  template. 
The  strategies  for  induction  are  tailored  for  the  defined  automaton  template, 
and  are  defined  in  the  file  pvs-strategies.  Therefore,  (2)  the  user  can  use  the 
specialized  environment  from  within  the  PVS  system.  Finally,  (3)  it  is  easy  to 
generate  human  readable  proofs  using  the  generic  strategies,  provided  that  the 
strategies  implement  proof  steps  meaningful  to  humans. 

A  slightly  different  approach  has  been  taken  by  the  developers  of  DisCo  [6, 
5],  where  the  PVS  specification  of  the  automaton  is  processed  by  a  “generator” 
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to  produce  the  proof  scripts.  One  advantage  of  this  approach,  due  to  the  clearly 
defined  interface  between  the  theorem  prover  (PVS)  and  the  specialized  environ¬ 
ment  (DisCo),  is  that  the  generated  proof  scripts  are  relatively  insensitive  to  the 
modifications  of  the  internals  of  theorem  prover  commands  and  data  structures. 

However,  we  would  like  our  strategies  to  be  directly  applicable  to  all  automata 
specified  with  our  template  theory.  The  success  of  our  approach  does  depend 
on  access  to  the  data-structures  in  the  proof  state  maintained  by  PVS,  and 
the  consistency  of  the  behavior  of  PVS  proof  commands.  We  discuss  the  PVS 
support  necessary  to  achieve  this  in  Section  3. 


2.2  Abstraction  Proofs 

Given  automata  A  and  C,  it  is  often  useful  for  the  purposes  of  verification  to 
show  that  there  exists  an  abstraction  relation  between  them.  Several  kinds  of 
abstraction  relation,  e.g.,  homomorphism,  refinement,  forward  and  backward 
simulation,  etc.,  are  described  in  the  literature,  and  there  may  also  be  other 
such  relations  of  interest. 

Abstraction  proofs  can  be  performed  directly  by  specifying  both  automata 
A  and  C,  and  the  abstraction  relation  between  them,  within  the  same  PVS  the¬ 
ory.  However,  this  approach  makes  it  difficult  to  construct  generic  strategies  for 
automating  the  proofs,  and  to  use  invariants  which  have  been  proved  separately 
for  the  individual  automata. 

Instead,  we  intend  to  make  use  of  PVS  support  for  theory  parameters ,  as  fol¬ 
lows.  Two  parameters  A  and  G  of  the  type  automaton  theory  (Figure  1)  can  be 
passed  as  parameters  to  the  theory  abstraction  (Figure  2),  which  also  takes  the 
abstraction  relation  absrel  and  the  action  map  actmap  as  parameters.  The  the- 

automaton:  THEORY 
BEGIN 

actions  :  TYPE+; 

stutter:  actions; 

visible  (a: actions)  :  bool; 

states  :  TYPE+; 

start  (s: states)  :  bool; 

enabled  (a: actions,  s: states)  :  bool; 

trans  (a: actions,  s: states)  :  states; 

stutter_trans_ax:  AXIOM  (FORALL  (s:states):  (trans (stutter , s)  =  s)); 
stutter_enabled_ax:  AXIOM  (FORALL  (s:states):  (enabled(stutter , s) ) ) ; 

reachable  (s: states)  :  bool; 
equivalent  (si,  s2 :  states)  :  bool; 

END  automaton 


Fig.  1.  The  automaton  abstract  theory 
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ory  abstraction,  which  somewhat  resembles  the  theory  groupJiomomorphism 
in  [12]  for  setting  up  proofs  of  homomorphism  between  groups,  defines  the  ab¬ 
straction  relations  between  the  two  interpretations  of  the  automaton  theory.  To 
pass  actual  theory  parameters  to  groupJiomomorphism,  the  various  elements  of 
the  group  theories  must  be  named:  the  members  of  the  groups,  identities  and 
composition  operators,  etc.  But,  when  individual  automata  follow  the  same  nam¬ 
ing  conventions  as  in  the  theory  automaton,  a  shortcut  is  in  principle  possible  in 
passing  actual  theory  parameters  to  abstraction:  because  the  various  elements 
of  the  actual  parameters  can  be  matched  to  the  formal  parameters  syntactically, 
only  the  actual  theory  names  need  to  be  provided.  A  modification  to  PVS  that 
will  allow  this  shortcut  is  under  construction  at  SRI. 


abstraction  [A,  C:  automaton, 

actmap:  [C. actions  ->  A. actions], 

absrel:  [C. states,  A. states  ->  bool]  ]  :  THEORY 

BEGIN 

a_C  :  VAR  C. actions; 
a_A  :  VAR  A. actions; 
s_C,  sl_C,  s2_C:  VAR  C. states; 
s_A  :  VAR  A. states; 

vis_ax:  AXOIM 

(FORALL  a_C:  C. visible (a_C)  =>  A. visible (actmap (a_C) )) ; 
invis_ax:  AXIOM 

(FORALL  a_C:  N0T(C. visible (a_C) )  =>  (actmap(a_C)  =  A. stutter)); 

weak_ref inement_base  :  bool  = 

(FORALL  s_C,  s_A: 

C.start(s_C)  ft  absrel(s_C,  s_A) 

=>  A . start (s_A) ) ; 

weak_ref inement_step  :  bool  = 

(FORALL  s_C,  sl_C,  a_C,  s_A: 

C.reachable(s_C)  ft 

C. equivalent (s_C ,  sl_C)  &  C. visible(a_C)  ft  C. enabled (a_C,  sl_C)  & 
A.reachable(s_A)  ft 
absrel (sl_C,  s_A) 

=>  A. enabled (actmap (a_C) ,  s_A)  & 

(EXISTS  (s2_C :  C. states): 

C. equivalent (C.trans(a_C,  sl_C) ,  s2_C)  ft 
absrel(s2_C,  A .trans (actmap (a_C) ,  s_A)))); 

weak_ref inement  :  bool  =  weak_ref inement_base  ft  weak_refinement_step; 
END  abstraction 


Fig.  2.  The  abstraction  theory 
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The  actmap  relation  in  the  theory  abstraction  maps  an  action  of  the  con¬ 
crete  automaton  C  to  an  action  of  the  abstract  automaton  A.  The  axioms  vis_ax 
and  invis_ax  that  indicate  that  the  visible  actions  in  C  map  to  visible  actions  in 
A  and  invisible  (i.e. ,  internal)  actions  in  C  map  to  the  stutter  step  in  A,  become 
proof  obligations  when  abstraction  is  instantiated.  At  the  same  time,  the  ax¬ 
ioms  stutter_trans_ax  and  stutter_enabled_ax  from  the  theory  automaton 
will  become  proof  obligations  with  respect  to  both  automaton  theory  instances. 

For  abstraction  proofs  the  theory  abstraction  assumes  a  role  analogous 
to  that  of  the  theory  machine  in  the  case  of  induction  proofs,  in  that  it  will 
define  the  abstraction  relations  and  also  establish  the  theorems  (e.g.,  concerning 
trace  inclusion)  that  are  the  consequences  of  the  existence  of  such  relations 
between  pairs  of  automata.  In  Figure  2,  only  one  sort  of  refinement  relation  has 
been  defined;  in  practice,  the  theory  abstraction  will  define  all  possible  useful 
abstraction  relations  between  the  two  automata.  The  theory  abstraction  will 
thus  provide  us  with  a  starting  point  for  developing  generic  strategies  for  proving 
abstraction  relations. 

3  PVS  Support 

In  this  section  we  suggest  some  PVS  features  which  would  be  helpful  for  writing 
strategies,  particularly  for  the  above  types  of  proofs. 

1.  Naming  in  theory  interpretations.  The  abstraction  proofs  involve  many 
related  theories,  for  example  different  instances  of  automatonName- decl, 
automatonName- inv,  machine,  etc.  It  is  difficult  to  write  general  strate¬ 
gies  that  involve  formulas  or  definitions  in  multiple  theories:  the  user  often 
has  to  identify  the  particular  theory  instances  explicitly.  It  would  be  useful 
for  strategy  writers  if  PVS  provided  well  documented  naming  conventions 
and  functions  for  determining  theory  instances  associated  with  names,  and 
supported  the  automatic  context-based  selection  by  user  strategies  of  appro¬ 
priate  theory  instances  for  names. 

2.  Functions  to  access  information  in  specification  and  in  proof  states. 

A  strategy  often  depends  on  the  nature  of  the  automaton  specification.  It 
can  also  make  choices  based  on  the  current  proof  state.  The  CLOS  structure 
used  by  PVS  provides  functions  to  access  various  slots  of  the  current  proof 
state  object.  However,  these  are  not  guaranteed  to  be  fixed,  and  indeed  can 
sometimes  change  dynamically.  For  writing  strategies  it  would  be  helpful 
if  functions  to  access  the  definitions  in  a  particular  theory — for  example 
the  invariance  lemmas  or  the  action  definitions — and  functions  for  accessing 
parts  of  a  sequent,  formulae,  etc.,  were  provided  as  a  part  of  a  PVS  strategy 
language. 

3.  Documentation  of  implementation  details  in  PVS  proof  commands. 

The  LISP/CLOS  functions  used  in  writing  the  internal  PVS  strategies  (e.g., 
induct)  are  not  well  documented.  Many  of  these  functions,  for  example 
typep,  tc-eq,  can  be  useful  for  writing  new  strategies.  Therefore,  proper 
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documentation  of  these  functions  would  save  effort  and  help  new  strategy 
writers  learn  the  art. 

4.  Improved  support  for  maintaining  compatibility  with  PVS.  The  ef¬ 
fects  of  some  basic  PVS  commands  (e.g.  SKOLEM,  EXPAND)  have  altered  over 
PVS  versions  owing  largely  to  changes  in  PVS’s  decision  procedures  and  their 
use  in  conjunction  with  such  basic  steps.  As  a  result,  strategies  developed  for 
older  versions  of  PVS  do  not  always  work  in  the  newer  PVS  versions.  There¬ 
fore,  it  is  highly  desirable  to  provide  a  feature  in  future  versions  of  PVS  that 
would  allow  strategies  to  invoke  prover  commands  and  get  the  same  result 
as  in  some  specified  previous  version.  Because  most  changes  in  effects  appear 
to  involve  the  decision  procedures  and  their  hidden  uses,  there  should  at  the 
very  least  be  optional  versions  of  proof  steps  that  decouple  them  from  any 
use  of  these  procedures. 

4  Conclusions 

Domain  specific  theorem  proving  is  a  practical  means  for  harnessing  the  power 
of  mechanical  theorem  provers  for  system  design  and  analysis.  In  this  paper 
we  have  outlined  design  principles  for  the  development  of  proof  strategies  of 
a  specialized  theorem  proving  environment  for  hybrid  I/O  automata  based  on 
PVS.  Our  aim  is  to  make  the  more  complex  component  of  the  environment — the 
proof  strategies — generic,  based  on  a  specific  HIOA  template,  leaving  the  simpler 
component — the  specification — to  be  written  by  instantiating  the  template.  We 
have  outlined  the  support  we  believe  would  help  us  develop  effective  generic 
strategies. 
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